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(57) Abstract: A computer system (200/300) has a main system (200) to execute an application (A) in cooperation with a human 
user (1000). The auxiliary system (300) evaluates problems (P) in the main system (200). The auxiliary system (300) has a service 
module (310) to collect problem related data (D) from the main system (200), an acquisition module (320) to acquire knowledge 
representations (R), a knowledge module (330) to store knowledge representations (R), an inference module (340) for processing 
problem related data (D) with knowledge representations (R) to identify solutions (S) and for forwarding the solutions (S) through 
the service module (310) to the main system (200). The auxiliary system (200) distinguishes context of the problems (P) and distin- 
guishes versions of the main system (200). 
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IDENTIFYING SOLUTIONS TO COMPUTER PROBLEMS BY EXPERT SYSTEM 
USING CONTEXTS AND DISTINGUISHING VERSIONS 

01 Field of Invention 

02 The present invention generally relates to data processing by 
computer systems, programs, and methods. More particularly, the 
invention relates to evaluating and solving problems. The 
computer systems are distinguished into main, auxiliary and 
service systems. 

03 Background 

04 Electronic data processing uses integrated and distributed 
computer systems with complex architecture. Coupling different 
computers over networks (e.g., Internet) enhances functionality 
but adds complexity and increases maintenance. 

05 Each computer system operates in the complexity of hardware 
(e.g., computers and network) and software (e.g., operating 
systems, applications, databases) . 

os Problems are deviations from the predefined operation of the 
computer system that are caused by malfunction of hardware or 
software or by improper input by the user. To name a few 
examples, components like processors suddenly fail, 
applications occasionally provide wrong results, and users 
sometimes manipulate data. 

07 Problems often remain hidden from the user. Once detected, the 
user engages in problem solving. For example, the user reads 
documentation papers, activates help functions (e.g., 
predefined advices, often obtained via online services), looks 
up in databases to identify advices ("notes"), makes 
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experiments, or tells problem symptoms to specialists (e.g., 
through phone hotline, email, Internet portal) . 

08 A majority of users relies on passive assistance; only a 
minority actively solves the problem. There are further 
challenges: For example, sensitive data remains with the 
authorized user but is shielded from specialists (data 
protection) ; users and specialists might introduce further 
errors. In any case, problem solving remains time consuming and 
expensive. 

09 Further, heterogeneous system landscapes have systems that 
differ for example, by manufacturer, release version, and 
application. Each difference increases the number of potential 
problems and corresponding solutions. Selecting solutions 
becomes critical. 

010 There is a need to improve problem solving by mitigating 
disadvantages of the prior art. 

on Brief Description of the Drawings 



012 FIG. 1 illustrates a simplified block diagram of a computer 

system with a main system and an auxiliary system 
according to the present invention; 

013 FIG. 2 illustrates the system of FIG. 1 with more detail; 

014 FIG. 3 illustrates a service module in the auxiliary system 

with more detail; 

015 FIG. 4 illustrates an acquisition module in the auxiliary 

system with more detail; 

016 FIG. 5 illustrates a knowledge module in the auxiliary system 

with more detail; 

017 FIG-. 6 illustrates an inference module in the auxiliary system 

with more detail; 
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018 FIG. 7 illustrates a first distributed system landscape with 

the main and auxiliary systems coupled to a service 
system; 

019 FIG. 8 illustrates a second distributed system landscape with 

2 main systems coupled to a service system; 

020 FIG. 9 illustrates a simplified flowchart diagram of a method 

for operating the main, auxiliary and service systems; 

021 FIG. 10 illustrates a simplified scenario that considers 

interaction, and thereby distinguishes automatically 
problem evaluating and semi -automatically problem 
evaluating; 

022 FIG. 11 illustrates a simplified scenario that considers 

primary and secondary context; 

023 FIG. 12 illustrates a simplified scenario that considers the 

distribution of problem collecting and solution 
processing in the system landscapes; 

024 FIG. 13 illustrates further simplified scenarios; 

025 FIG. 14 summarizes various aspects of the present invention by 

concentrating on an inference module; and 

026 FIG. 15 illustrates a simplified block diagram of a computer 

system in general for that the present invention can be 
implemented . 

027 Detailed Description 

028 An exemplary implementation for the invention uses the well- 
known system R/3. R/3 is commercially available from SAP 
Aktiengesellschaf t Walldorf (Baden, Germany, "SAP"). 
Organizations (i.e. SAP customers) use enterprise resource 
planning applications ("ERP applications" , or "business 
applications") to organize information in a variety of fields, 
such as supply chain management (SCM) , customer relationship 
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management (CRM) , financials, human resources (HR) , enterprise 
portals, exchanges, technology, product lifecycle management 
(PLM) , supplier relationship management (SRM) , business 
intelligence, business intelligence, mobile business, hosted 
solutions, small and midsize business, and industry solutions. 

029 ABAB/4 is the well-known programming language used by SAP to 
define transactions for applications. R/3 and ABAB/4 is 
documented by a variety of reference, books, such as: 

030 Gareth M. de Bruyn, Robert Lyfareff, Ken Kroes: "Advanced ABAP 
Programming for SAP". Prima Publishing 1999. ISBN 0-7615-1798- 
7. 

031 Bernd Matzke: "Programming the SAP R/3 System". Addison- Wesley, 
1997. ISBN 0-201-92471-4. 

032 Jonathan Blain, ASAP World Consultancy: "Special Edition Using 
SAP R/3, Third Edition. Que. 1999. ISBN 0-7897-1821-9. 

033 A detailed description of a computer system in general and a 
list of reference numbers are provided as the end of the 
specification. 

034 In short, according to the invention, a computer system has a 
main system to execute an application (A) in cooperation with a 
human user and has an auxiliary expert system to evaluate 
problems (P) in the main system. Optionally, the problems are 
solved by predefined instructions. > 

035 The auxiliary system uses knowledge representations (R) in 
primary and secondary contexts. The auxiliary system 
distinguishes versions of the main system and - optionally - 
versions of the application (A) . Knowledge representations (R) 
are classified into context groups. 



2002P10027WO 



WO 2004/040510 




PCT/EP2003/0 10246 



- 5 - 

036 The present invention enables the user to actively solve 
problems in the main system mostly without asking for advice by 
human specialists. Applying the invention saves time and 
quickly returns the main system back to normal operation. 
Applying further features effectively escalates problem 
evaluation to the service system. Involving human specialists 
(often expensive) is only required as a last remedy. 

037 FIG. 1 illustrates a simplified block diagram of a computer 
system with main system 200 and auxiliary system 300 according 
to the present invention. 

038 Computer system 200/300 has main system 200 to execute 
application A in cooperation with human user 1000. Auxiliary 
system 3 00 evaluates problems P in main system 200. Auxiliary 
system 3 00 has service module 310 to collect problem related 
data D from main system 200, acquisition module 320 to acquire 
knowledge representations R, knowledge module, 330 to store 
knowledge representations R, inference module 340 for 
processing problem related data D with knowledge 
representations R to identify solutions S and for forwarding 
the solutions S through service module 310 to main system 200. 
Throughout the modules, auxiliary system considers context and 
versions (of main system 200 and application A) . 

039 Auxiliary system 300 finds problem related data D by evaluating 
the problem environment in main system 200: date, time, memory 
usage, data objects, software modules of application and 
operating system and the like. 

040 FIG. 2 illustrates main system 200 and auxiliary systems 300 
with more detail. Main system 200 has a client/server 
configuration with database 210 (preferably, relational 
database), application server 220 and front-end server 230. 
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041 The following refers to an exemplary implementation: Main 
system 200 and auxiliary system 300 are implemented by an R/3 
type system. System 200 performs an ERP application. The ERP 
application is defined by instructions that have common 
keywords, common syntax and common semantic with environments 
selected from the group of: ABAB/4, Java 2 Platform Enterprise 
Edition ( J2EE) , and.NET framework. Auxiliary system 300 uses 
the client/server configuration (210 , 220 f 230) of main system 
200: the modules of auxiliary system 300 are distributed such 
that service module 310, acquisition module 320 , knowledge 
module 330 , inference module 340 are arranged in parallel to 
application server 220 and to database 210. Front-end server 
230 operates as user -interface both for main system 200 and 
auxiliary system 300. In other words, database 210 implements a 
storing function, application server 220 implements the 
application (A, cf . FIG. 1) and front-end server 230 implements 
presentations (e.g., user interface). The module distributions 
can be modified. For example, knowledge module 33 0 can be part 
of database 210 . Internet communication is used between 
application server 220 and front-end server 230. Internet 
communication is implemented by well-known techniques (e.g., 
TCP/IP, HTML, and HTTP) . 

042 Having introduced main system 200 and auxiliary system 300 in 
general, the following sections describe the modules with more 
detail. 

043 FIG. 3 illustrates service module 310, especially its 
cooperation with main system 2 00 (dashed frame) in the 
exemplary implementation. Service module 310 makes basis 
service functions of main system 200 available for auxiliary 
system 3 00 (cf . FIG. 2) . Basis service functions are: ABAP/4 
workbench, administration, authorizations, batch input, data 
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dictionary, dialog control, framework, graphical user 
interface, application program interface, and job. Basis 
services are explained in the above-cited reference books. 

044 Service module 310 cooperates with main system 200 to obtain 
problem related data D for auxiliary system 3 00. Service module 
310 cooperates with database 210 to test the existence of 
objects: The problem related data D comprises information about 
existence and non-existence of the objects. The objects are 
related to application A (in server 220) . 

045 Service module 310 cooperates with database 210 to obtain the 
content of a table entry as problem related data D. Service 
module 310 records events in the operating system of main 
system 200 by writing to database 210. Service module 310 
records problem related data D obtained from data consistency 
check operations of main system 200 (e.g., application server 
220) . Consistency checks determine consistency (non- 
consistency) of data in database 210, especially in the 
database tables: Entries in the table-body should be consistent 
with the entries in the table-header. For example, the body 
holds zip-code numbers below headers "zip-code". Service module 
310 instructs front-end server 230 to provide dialogs with user 
1000. Service module 310 provides remote function call (RFC) 
connections with further auxiliary systems (with similar 
modules), such as with a service system (cf. FIG. 6). 

046 Service module 310 monitors application server 220 and database 
210 according to instructions from inference module 340. 

047 FIG. 4 illustrates acquisition module 320 for the exemplary 
implementation. Acquisition module 320 also modifies knowledge 
representations R. Acquisition module 320 interacts with 
knowledge engineer 1001, as illustrated, through tree 322 on a 
graphical user interface. Acquisition module 320 uses tree 322 
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to represent the knowledge representations R as a semantic net. 
Engineer 1001 may use well-known edit or drag and drop 
techniques to manipulate the representations. 
048 Knowledge engineers are, for example, (a) software developers 
who are familiar with main system 200, (b) technical writers 
who write documentations for customers, and (c) persons that 
have gathered experience as being a user (cf . 1000 in FIG. 1) . 
Tree 322 assists engineer 1001 to modify knowledge 
representations. As in the example, tree 322 represents a rule 
relating to a patch type. The rule has a query step (Download 
OK?) and conditional steps. A patch is distinguished by its 
source between Compact Disk, OSS (online service system, cf . 
reference books), and Internet. Depending on the source, 
different advices can be defined. Also, user 1001 is invited to 
modify tree 322 by inserting icons from an icon tray ("insert 
objects") . 

049 FIG. 5 illustrates knowledge module 330 for the exemplary 
implementation. Knowledge module 33 0 stores knowledge 
representations R by classifying into context, for example, 
business transactions as part of the application A, executable 
programs as part of the application A, and hierarchy level 
within the application A. 

oso Optionally, knowledge module 330 uses lexicon 331 to 

distinguish versions of main system 200 (e.g., versions "1.0" 
and "2.0"). Lexicon 331 defines parameters Pa (for a particular 
version) and knowledge representations R (for all versions) . 
The figure illustrates the different parameters by different 
hatching. Distinguishing is very convenient if auxiliary system 
300 serves 2 or more main systems 200 that have different 
version (i.e. release or language). For example, main systems 
200 might differ in their table definitions due to different 
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release dates. Distinguishing through parameters for equal 
representations helps to keep the number of knowledge 
representations at a convenient level. Useful is also to 
distinguish between different natural languages: For example, 
while a first main system communicates with its users in 
German; a second main system communicates with its users' in 
English; both mains systems are supported by a common auxiliary 
system that provides dialog texts in English or German. 
Knowledge module 330 makes the knowledge representations R 
selectively available or non- available according to a selected 
context or version. 
051 Knowledge module 330 distinguishes context with primary context 
and secondary context, wherein the secondary context is 
referenced from the first context. The first context can refer 
to the second context, the second context can refer to the 
first context, or both contexts can refer to each other. 
Knowledge module 330 selects knowledge representations R to be 
considered by inference module 340 according to the context of 
a current transaction by the application server 220. Selected 
context is selected by user 1000 or by a predefined rule. For 
example, the context is selected from: system and program 
performance, background processing, OCS and patches, data 
dictionary, printer problems, remote function calls and 
connectivity, R/3 reporting, and security and administration. 
052 For example, the first context is defined by the application 
with a transaction "Patch Manager". Problem P and data D are 
"Patch not found". Knowledge representations R have hints to 
find a storage location for patches (e.g., a directory or a 
server) . But processing does not result in a solution S. The 
problem remains unsolved. However, the link "Transport" refers 
from the first context to the second context. The second 
context leads to knowledge representations R to software 
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installing procedures. Processing with these representations R 
leads to solutions S. 

053 Knowledge module 330 is adapted to receive regular updates of 
the knowledge representations R (arrow symbol) . The updates can 
originate, for example, from a service system (cf . FIG. 5) that 
acts as further auxiliary system. Knowledge module 330 stores 
knowledge representations R in database 210 with entries for 
specific problem P symptoms and corresponding solutions S. 

054 Knowledge module 330 stores knowledge representations R that 
point to predefined solution identification rules in database 
210 (or in module 330 itself) . The solution identification 
rules are provided in a meta language. The meta- language is 
derived from ABAP/4. 

055 The rules usually identify action, object, arguments and result 
location. An example for meta language is, for example, a 

2 -line rule for storing data. The first line reads as "CALL" 
(action), "FUNCTION" (object), "GETJETLEJPATH" (argument), and 
"FILE__PATH" (result location) to find a file directory (path) 
and to keep the file directory in a first variable ("FILE 
PATH"). The second line reads as "CHECK_EXIST» (action), "FILE" 
(object), " <FILE_PATH> / rf c . trc " (argument) and "EXIST" (result 
location) to check the existence of file "rfc.trc" in the 
directory and to write existence/absence result into a variable 
("EXIST") . 

056 Providing R in meta- language in convenient for automatically 
processing. Markup languages (e.g., XML) are also useful. It is 
an advantage that R can also be provided partially or 
completely in natural languages (e.g., English) for 
"processing" by a human. 

057 Knowledge module 330 generates a structured set of problem 
solving strategies, such as so-called "troubleshooting guides". 



2002P10027WO 



WO 2004/040510 ^^PCT/EP2003/0 10246 



- 11 - 



These are strategies for consideration by a specialist or by 
the user. 

058 Knowledge module 330 generates solution identification rules 
with computer instructions that the computer utilizes to 
automatically solve the problem. Preferably, knowledge module 
330 distinguishes error classes (details below) . 

059 Sets of semantically related solution identification rules are 
grouped together, such as rules to find the problem 
"inconsistency in a table" , and rules to find the corresponding 
code to "automatically re-arrange the table" (i.e. utilizing 
the solution) . Tables in the database 210 are not only used to 
organize data for application A, but also convenient for 
knowledge module 330 to stores knowledge representations R. In 
that case, the tables are provided prior to activating 
auxiliary system 300. 

060 The following is an example for using knowledge representations 
R, context and check lexicon: The knowledge representations 
form a set of Rl, R2, R3, R16, R99 (consecutively 
numbered) . Each R is defined by met a- language, such as "CHECK 
PRINTER CONNECTION" for R16 . 

061 Context are subsets of representations for that relate to 
problem classes, such as context PRINTER with R5, R6 and R16 . 
The check lexicon lists details for knowledge representations 
depending on versions of main system 200 (optionally versions 
of application A). R16 for version 3.0 testing an IP connection 
by a standard "PING PRT" command to the printer; for version 
3.1 calling a dedicated test function (in auxiliary system 

3 00); for version 4.0 instructing the printer to print a test 
page. 

062 When processing problem data D such as "printing not possible" 
for main system 300 of version 3.0, auxiliary system 200 
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extract the context set PRINTER from all R, checks the lexicon 
for applicable details and applies each R in combination with 
the details (e.g., R16 PING PRT) . If a solution is still 
missing, the context changes, for example, to GENERAL with Rl 
"CHECK POWER SUPPLY" . Applying Rl - this time without 
distinguishing versions - leads to a success. The printer was 
not connected to the mains power. The solution S is identified 
as a message to the user that is forwarded to the user (in the 
further context of the English language, through the front-end 
server) : "Please connect your printer to the 230 volts power 
supply. " 

063 FIG. 6 illustrates inference module 340 in auxiliary system 300 
with more detail. Inference module 340 identifies the solutions 
S from sets of predefined advices" (preferably, advices of 
application A) by a solution identifier. 

064 Inference module 340 identifies the solutions by applying the 
knowledge representations R (to data D) in a predefined order 
that is, for example, a sequential order (e.g., Rl, R2, R3) , a 
hierarchical order (e.g., Rl, R21, R21, R31, R32) , a 
dynamically adaptive order in that the order might chance by 
conditional jumps or the like (e.g., IF THEN). 

065 Inference module 340 communicates questions to user 1000 (cf . 
Ql, Q2, Q3 reservoir) . Preferably, the questions are standard 
questions. Inference module 340 consecutively numbers the 
questions. Inference module 340 composes the questions from 
predefined passages that are provided by application server 
220. inference module 340 analyzes the responses that user 1000 
enters in natural language (cf . language analyzer) . 

066 So far the exemplary implementation has been described with 
main system 200 and auxiliary system 300 that communicate by 
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basis functions and that are implemented by a single R/3 
system. Distributing modules of auxiliary system 3 00 to a 
client/server system configuration is convenient- The invention 
is however not limited to that. Further implementations benefit 
from the following: 

(a) Main and auxiliary systems can be distributed to different 
computer systems (e.g., different R/3 systems; cf. FIG, 7). 

(b) A further auxiliary system (here called service system) can 
provide enhanced problem evaluation capacities (cf . 

FIG. 7) . 

(c) One auxiliary system can serve 2 or more main systems (cf . 
FIG. 8) . 

d) Applicable knowledge representations can be selected for a 
particular version of the main system, for example, by 
maintaining a check lexicon. 

e) A first auxiliary system starts to evaluate the problem by 
first knowledge representations and forwards evaluation 
results to a second auxiliary system. The second auxiliary 
system then returns a second (enhanced) knowledge 
representation to enable the first auxiliary system to 
finish the evaluation. 

067 For convenience of explanation, the following uses the term 
"system 200/300" collectively for the combination of main 
system 200 with auxiliary system 300 for main system 200 alone. 
In other words, auxiliary system 300 is not longer required in 
any case. 

068 FIG. 7 illustrates a first distributed system landscape with 
system 200/3 00 coupled to a service system 500 via a network. 
Service system 500 has auxiliary components with functions that 
are substantially similar to that of auxiliary system 3 00: 
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service module 510, acquisition module 520, knowledge module 
530, inference module 540 as well as modules for front-end 
communication. The foregoing description is applicable for 
these modules as well. 
069 Preferably, system 500 operates independently from any main 

system and does not execute an ERP application. Optionally but 
not mandatory, service system 500 has a client/server 
configuration, such as system 500 in an exemplary 
implementation being an R/3 type system. In comparison to 
system 200, service system 500 uses knowledge representations R 
that are enhanced in terms of volume, actuality, and 
complexity. If required, system 500 also solves problems in 
auxiliary system 300. In short, system 500 has at least the 
above-mentioned functions of auxiliary system 3 00 and serves as 
the expert system for system 200/300. 

070 Service system 500 is conveniently installed at a 
manufacturer's site (of system 200/300) and communicates with 
system 200/300 by receiving problem data (D) from system 
200/300 and sending control instructions (C) to system 200/300. 

071 Service system 500 is - optionally - operated by service 
engineer 1002 who helps to solve problems in system 200/300. 
Dynamic enhancement is possible: control instructions C are 
conveniently also used to regularly update knowledge module 330 
with actual knowledge representations (R, cf. FIG, 5 updates). 

072 If system 200/300 is implemented with auxiliary system 300, 
then auxiliary system 300 acts as a first expert system and 
service system 500 act as a second expert system. Depending on 
the severity of the problem (in system 200), problems are 
evaluated as follows: 

073 (1) Auxiliary system 200 solves the problem (i.e. solutions S 

are identified by system 300) . 
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074 (2) Auxiliary system 200 does not solve the problem but 

forwards a package with, problem P data in combination with 
preliminary solutions S {i.e., P/S data, based on knowledge 
representations (R) in system 200) to service system 500. 
Service system 500 then solves the problem. 

075 (3) Auxiliary system 200 does not solve the problem but 

forwards the P/S data package to service system 500. System 
500 uses the P/S data to return further knowledge 
representations. This enables system 200 to evaluate and 
solve the problem. 

076 (4) Service system 500 does not solve the problem automatically 

and needs to interact with service engineer 1002 (further 
analysis by a human technician) . 



077 PIG. 8 illustrates a second distributed system landscape with 
main systems 201 and 202 coupled to service system 500. The 
approach of FIG. 7 has been expanded by adding a further main 
system. Optionally, service system 500 is operated by a service 
engineer (cf. 1002). 

078 In the exemplary implementation, main system 201 is physically 
implemented on a first computer; main system 202 (as system 201 
also in client/server configuration) is implemented on a second 
computer, service system 500 is implemented on a third 
computer. Auxiliary systems are optionally added to main 
systems 201 and 202. 

* 079 Main system 201 is adapted to be operated by a first customer 
(e.g., a first company), service system 500 is implemented by 
expertise service provider ESP and main system 202 is adapted 
to be operated by a second customer (e.g., a second company) . 
For example, ESP is the manufacturer of systems 201/500/202 or 
is a consulting agency. Preferably, main systems 201 and 201 
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are systems of the same type (e.g., R/3) , but have different 
release versions (i.e. 201 older than 202, or vice versa) . 

080 Different release versions are distinguished by context groups, 
(cf . FIG. 5) . Such an arrangement is convenient also for main 
systems that communicate with their users in different natural 
languages. While problem identification is technically the same 
in systems 201/202, messages to users (e.g., notes, dialogs) 
can be in different natural languages. 

osi Some or all of the computers are located at physically 

different locations. Expertise of service system 500 becomes 
available around the globe. Service system 500 could 
simultaneously serve main systems 201/202 in different 
continents around the clock. 

082 Having service system 500 physically separated from main 
systems 201/200 has further beneficial effects: For example, 
expertise (i.e. knowledge representations R) is shielded from 
access by main system 201/202; and sensitive data on main 
systems 201/202 is shielded from access by service system 500. 

083 Further distributions of main, auxiliary and service systems 
are possible. For example, a plurality of main systems can be 
equipped with auxiliary systems that solve problems for their 
corresponding main system or forward problem data to service 
systems . 

084 FIG. 9 illustrates a simplified flowchart diagram of method 400 
for operating computer system 200/300. Method 400 is also 
applicable if auxiliary system 300 is replaced by service 
system 500. 

085 As stated above, system 200/300 has main system 200 executing 
application A in cooperation with human user 1000 and has 
auxiliary system 300 evaluating problems P in main system 200. 
According to method 400, auxiliary system 300 performs the 
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following steps: collecting 410 problem related data D from 
main system 200, acquiring 420 knowledge representations R, 
storing 430 knowledge representations R, processing 441 problem 
related data D with knowledge representations R to identify 
solutions S, and forwarding 442 the solutions S through service 
module 310 to main system 200. Method steps are also 
illustrated in FIG. 1 by arrows COLLECT, ACQUIRE, STORE, 
PROCESS , FORWARD . 

086 In the exemplary implementation, step collecting 410 is 
performed by service module 310; step acquiring 420 is 
performed by acquisition module 320; step storing 430 is 
performed by knowledge module 330; and steps processing 441 and 
forwarding 442 are executed by inference module 340. Modules 
310-340 have been explained in connection with FIGS. 1-6. 

087 in the exemplary implementation, steps collecting 410, 
acquiring 42 0, storing 430, processing 441 and forwarding 442 
are performed for main system 200 that has a client/server 
configuration with database 210, application server 220, and 
front-end server 230. Steps collecting 410, acquiring 420, 
storing 430, processing 441 and forwarding 442 are performed in 
modules 310, 320, 330, 340 (of auxiliary system 300) that are 
arranged in parallel to main system 200. 

088 Steps acquiring 420 knowledge representations R and forwarding 
442 solutions S comprise to operate a user- interface in front- 
end server 230 of main system 200. Steps collecting 410, 
acquiring 420, storing 43 0, processing 441 and forwarding 442 
are performed by basis service functions of main system 200. 

089 The following is optional for step collecting 410: Service 
module 310 cooperates with main system 200. Service module 310 
cooperates with database 210 to test the existence of objects: 
problem- related data D informs about existence and non- 
existence of the objects. Service module 310 cooperates with 
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database 210 to obtain the content of a table entry as problem 
related data D. Service module 310 records events in the 
operating system of main system 200 by writing to database 210. 
Service module 310 records problem related data D obtained from 
data consistency check operations of main system 3 00. Service 
module 310 instructs front-end server 230 to provide dialogs 
with user 1000. Service module 310 provides remote function 
call RFC connections with service system 500 (operating like a 
remote auxiliary system) . Service module 310 monitors 
application server 220 and database 210 according to 
instructions from inference module 340. 

090 The following is optional for step acquiring 420: Acquisition 
module 320 modifies the knowledge representations R. 
Acquisition module 320 interacts with a knowledge engineer. 
Acquisition module 320 interacts with the knowledge engineer 
through tree 322 on a graphical user interface (cf. FIG. 4). 
Acquisition module 320 uses tree 322 to represent knowledge 
representations R as a semantic net. 

091 The following is optional for step storing 430: Knowledge 
module 330 classifies the knowledge representations R into 
context groups. Knowledge module 330 organizes the context 
groups by lexicon 331 (cf. FIG. 5). Knowledge module 33 0 
defines the context by a version of main system 200 and defines 
lexicon 331 by knowledge representations for the versions. 
Knowledge module 330 makes the knowledge representations R 
selectively available or non-available according to a selected 
context for subsequent step processing 441. Knowledge module 
330 distinguishes context between primary context and secondary 
context. Knowledge module 330 stores knowledge representations 
R in database 210 with entries for specific problem P symptoms 
and corresponding solutions S. Knowledge module 330 stores 
knowledge representations R in database 210 with entries for 
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predefined solutions identification rules. Knowledge module 33 0 
stores knowledge representations R in a plurality of tables in 
database 210. 

092 The following is optional for step processing 441: Inference 
module 340 performs an action such as to: identify the 
solutions S form a set of predefined advices of the application 
A, identify the solutions S by applying knowledge 
representations R in a sequential order, identify the solutions 
S by applying knowledge representations R in a hierarchical 
order, identify the solutions S by applying knowledge 
representations R in a dynamically adaptive order, communicate 
questions to user 1000 by composing the questions from 
predefined passages provided by application A, analyse 
responses that user 1000 enters in natural language. 
093 Optionally, systems 200/300 cooperate with service system 500 
(cf. FIG. 7): While executing any of steps collecting 410, 
acquiring 420, storing 430 > processing 441 and forwarding 442, 
auxiliary system 300 conditionally forwards problem P data in 
combination with solutions S to service system 500. In the 
alternative, auxiliary system 300 forwards problem P data and 
solutions S for further analysis by a human technician. 
Auxiliary system 300 forwards problem P data and solutions S in 
a format that allows analysis by an expert system, for example 
by service system 500. 

094 In short, executing method 400 depends on a variety of 
circumstances- FIGS. 9-10 give exemplary overviews for 
scenarios that develop dynamically and that adapt the 
particular circumstances. 

095 For illustration, exemplary scenarios refer to interaction 
(FIG. 10) , context (FIG. 11) and distribution of problem 
collecting and solution processing (FIG. 12) . The following 
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description denotes queries by question marks. 



096 FIG. 10 illustrates a simplified scenario that considers 
interaction, and thereby distinguishes to automatically 
evaluate the problem and to semi -automatically evaluate the 
problem. Interaction occurs among systems 200, 300 and 500 and 
human user 1000. 

097 (10) Is interaction between main system 200 and auxiliary 

system 300 (or service system 500) required? 

The yes/no answer could depend on the performance 

during collecting or processing steps. 

098 (30) If no, system 200 continues to automatically evaluate 

the problem or continues with normal operation, usually 
in the absence of any problems. 

099 (20) If yes (interaction required) : What is the interaction 

type: user/system (U/S) interaction (e.g., 200, 300 or 
500 with. 1000) or system/ system (S/S) interaction 
(e.g., 200 with 300, 200 with 500, 300 with 500)? 

0100 (21) If user/system interaction, is the interaction 

initiated by a user or initiated by a system? 

0101 (22) If initiated by a user, for example, user 1000 detects 

a problem and starts a voluntary dialog with auxiliary 
system 300 or with system 500 at any time. A good 
opportunity for starting is to press a specialized 
button ("PROBLEM ANALYSIS") when viewing an error 
message. 

0102 (23) If initiated by a system, for example, system 300 

collects problem related data (D) by providing a 
mandatory dialog (system 300 with user 1000) . 

0103 (24) If system/ system interaction, is the interaction 

initiated by a user or initiated by a system? 
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0104 (25) If initiated by a user, for example, user 1000 starts 

the operation of 200/300 (cf. description method 400) 
or the operation of 200/500, 

0105 (26) If initiated by a system, for example, system 200/500 

starts its operation automatically. 

0106 The query order can be modified: the query for u/S or S/S 
interaction (10) could follow the initializing queries. U/S and 
S/S interactions and initializations can be related to each 
other . 



0107 FIG. 11 illustrates a simplified scenario that considers 
primary and secondary context. 

0108 (10) Processing problem data D to identify context (i.e. 

first context) and versions, thereby using lexicon 331 
(cf . FIG. 5) . 

0109 (20) Selecting knowledge representations R for that context 

(or version) . 

ono (3 0) Processing problem data D and knowledge representations 

R to find solutions S. 
om (40) Querying for the existence of a solution and finishing 

if solution exists. 
0112 (50) Repeating processing to identify further context (i.e. 

second or higher context, or other versions) and 

querying until a solution S is identified until all 

contexts have been considered. 



0113 FIG. 12 illustrates a simplified scenario that considers the 
distribution of problem collecting and solution processing for 
the various systems. The scenario is useful for distributed 
systems with main system 200, auxiliary system 300, and service 
system 500 (cf . FIGS. 7-8) . Depending on the availability of 
knowledge representations R (in auxiliary system 2 00 and in 
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service system 500) that match to problem data D, the problem 
is automatically evaluated and solution S is identified by 
auxiliary system 200 or service system 500 , or the problem is 
manually evaluated and the solution S is found by a human 
(e.g., user or technician). Modifications to the scenario 
(semi -automatically evaluating and solving) are also possible. 
The scenario substantially has the following phases: 
oii4 (10) Detecting the problem in main system 200. 
oils (20) Processing data D with R by auxiliary system 300 to 

identify a solution S (cf . method 400) . 
one (3 0) If processing successes to a solution S, solving the 

problem by auxiliary system 300. 
0117 (40) If processing fails (no solution) , forwarding data D to 
service system 500 (optionally enhancing D as described 
above) . 

oils (50) Processing data D with R by service system 500 to 
identify a solution S (applying method 400 
analogously) . 

0119 (60) If processing successes to a solution S, utilizing S 

(i.e. solve the problem) by service system 500 (or by 
auxiliary system 300 that is instructed by service 
system 500) . 

0120 (65) Optionally, supplying new R to auxiliary system (for 

finding a final solution by the auxiliary system) . 

0121 (70) If processing fails, evaluating the problem and finding 

S by a human. 

0122 Once a solution S has been identified, it can be applied to 
actually solve the problem in a similar scenario. 



0123 It is within the scope of the invention to superimpose such and 
other scenarios, for example, to have a scenario with 
interaction queries, with context consideration and with 
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distribution. 

0124 FIG. 13 illustrates simplified exemplary scenarios for solving 
problems in main system 200. Phases are given in top-down 
direction. Phases on the left side belong to the first 
exemplary scenario with automatically solving by the auxiliary 
system (illustrated on the left) ; phases on the right side 
belong to semi -automatically solving by forwarding enhanced 
data to service system 500. Processing phases are similar and 
therefore illustrated for both sides. 

0125 As illustrated for the first scenario, main system 200 reports 
a problem (i.e. problem P) ; auxiliary system 300 collects the 
data (cf. step 410) to analyze the problem environment (i.e., 
operating system; versions; tables) ; system 3 00 enhances the 
data by the problem environment; system 300 processes data (D) 
and knowledge representations (R) (problem analysis) to 
identify the solution (S) . (cf. FIG. 9, (10) (30)) 

0126 As illustrated for the second scenario, user 1000 initiates 
problem diagnosis, for example, main system 200 reports a 
problem (i.e. P) . Auxiliary system 300 processes data (D) and 
knowledge representations (R) , but does not identify a solution 
(e.g., R insufficient, D unknown). The user (or a computer 
specialist) manually collects further problem related data 
(e.g., about operating system); starts processing again to 
enhance the problem data (D) by environment data; re-processing 
by system 300 does however not result in a solution (S) . 
Therefore, the user decides to forward the enhanced problem 
data to service system 300. Service system then starts to re- 
evaluate the problem, usually with a more comprehensive set of 
knowledge representations (R) and solutions (S) . (cf . FIG. 9, 
(10), (20), (21), (22), (10), (20), (24), (26)) 
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0127 FIGS . 9-13 concentrate on examples. Further scenarios can be 
implemented, using other yes/no queries or case distinctions. 
Examples are explained in the following. 

0128 (a) Is there a need to manually input problem data D? For some 

cases, especially for rare problems, preparing 
comprehensive knowledge representations R is not possible 
(or too expensive) . The user can enter data via dialogs or 
other user interface elements. 

0129 (b) Does knowledge module 330 has a sufficient number of 

knowledge representations R? The number is usually 
sufficient if processing (step 441) results in solutions S. 
The number is usually insufficient if processing does not 
result in solutions S. In that case, activating acquisition 
module 320 and knowledge module 330 is possible to add or 
modify knowledge representations R. 

0130 (c) Does knowledge module 330 need to obtain further knowledge. 

representations R? This query is related to the previous 
one. Representations (R) can be obtained from distributed 
systems. For example, system 300 can obtain R from system 
500. This is convenient, for example, if system 300 
operates at a customer site (occasional update) and system 
500 operates at the site of a system manufacturer (daily 
update) . 

0131 (d) Are there updates available for modules 310, 320, 330, 340, 

for knowledge representations (R) or the like? Again, . 
updates can be loaded from system 500 to system 300. 

0132 (e) Is human support service available in a daylight time-zone 

to solve a problem in a night-light time- zone? If service 
systems 500 and specialists (i.e. service engineer 1002) 
are required, then system 200/300 could send a request to 
system 500 in a daylight time-zone. A 24 -hour- service can 
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0133 (f) 



0134 (g) 



0135 (h) 



0136 (i) 



0137 • 



0138 • 



be established with specialists working during daylight 
hours . 

Is there an emergency in solving the problem or is there 
allowable waiting time? Are there 2 or more problems with 
different urgency or priority levels? Prioritizing adds 
value; solutions to high-profile problems could be searched 
in parallel by system 300 and by system 500, 
Did the problem cause immediate symptoms? Some problems 
show symptoms only if they have become severe (e.g., a 
table with data overflow) . Auxiliary system 3 00 can 
evaluate the performance of the main system to find 
problems before they appear to the user. Conveniently, 
systems 3 00 or 500 operate in the background to identify 
hidden problems and operate in the foreground (i.e. with 
interaction) to solve visible problems. 
Having the solution identified, is there a predefined 
instructions sequence assigned to that solutions to 
automatically solve the problem? Automatic (or semi- 
automatic) problem solving according to predefined 
instructions could follow processing. 

It the problem classified in a particular error class? 
Problems and their corresponding solutions can be 
classified in great variety. Exemplary classes are: 
Class "information" , auxiliary system 300 informs user 1000 
about application details that are usually not critically 
to main system 200; 

Class "operation error", user 1000 does not properly 
operate system 200 (e.g., by accident), system 200 does not 
behave as specified, such problems can be solved, for 
example, by informing user 1000 through messages. 
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0139 • Class "performance", system 200 exhibits relatively long 

response times; problems like this are often related to 
hardware failure or to overflow of tables. 

0140 • Class "wrong result" , system 200. operates stable, but 

results are calculated incorrectly or inconsistently, 
exemplary solutions are consistency correcting or 
debugging . 

0141* Class "system error", system 200 detects an invalid 
processing step; an exemplary solution is the 
identification of the system module that causes the error 
(tracking function) . 

0142* Class "cancellation", system 200 partly or completely stops 
to operate, an exemplary solution is to reproduce the 
error . 

0143 (j) Can evaluating (i.e. method 400) be repeated with modified 

parameters (i.e. iteration with different D, R, or S)? 

0144 Without departing from the scope of the invention, persons of 
skill in the art may add further functionality, such as for 
context retrieval, long- text messages, heuristics, artificial 
intelligence, or exception handling. 

0145 FIG. 14 summarizes various aspects of the present invention by 
concentrating on inference module 340/540 (collectively x40) . 
As explained above, inference module x40 processes problem 
related data D with knowledge representations R to identify 
solutions S . 

0146 Modules that make inference module x40 an integral part of an 
expert system (i.e. provide expertise functionality) have been 
explained above: modules for obtaining D and R (e.g., collect, 
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acquire , store) , to use S and - optionally - to interact with a 
human user. 

0147 Briefly, inference module x40 has expertise functionality for 
evaluating problems P in main computer system 2 00 that executes 
an application A. Inference module x40 is adapted to process 
problem related data D with knowledge representations R to 
identify solutions S. For example, inference module x40 has one 
of the following configurations: 

0148 In a first configuration, inference module x40 is part of 
auxiliary computer system 300 that uses basis functions of main 
computer system 200. Main computer system 200 and auxiliary 
computer system 300 are client/server systems. 

0149 In a second configuration, inference module x40 is part of 
service system 500 that receives problem related data D from 
main computer system 200 over a network and that returns 
solutions S to main computer system 200. In a first case, 
service system 500 returns solutions S that solve the problem 
directly. In a second case, service system 500 return solutions 
S that solve the problem indirectly by being further knowledge 
representations for a further inference module (e.g., module 
340) . 

0150 In a third configuration, inference module x40 distinguishes 
problem related data D and - optionally - knowledge 
representations R in context classes. 

0151 In a fourth configuration, inference module x40 is part of 
service system 500 that receives problem related data D from 
first and second main systems 201, 202 of different versions 
over a network. Inference module x40 applies knowledge 
representations R for both main systems 201, 202 and 
distinguishes version differences of the main systems by 
looking up in check lexicon 331. 

2002P10027WO 



WO 2004/040510 



TCT7EP2003/010246 



- 28 - 

The present invention can also summarized as follows: 

0152 Preferably, selected context is selected by user 1000. 
Preferably, selected context is selected by a predefined rule. 
Preferably, knowledge module 330 applies a predefined rule to 
select knowledge representations R to be considered by 
inference module 340 according to the context of a current 
transaction in application server 220. Preferably, context is 
selected from the group of: system and program performance, 
background processing, OCS and patches, data dictionary, 
printer problems, remote function calls and connectivity, R/3 
reporting, and security and administration. Preferably, main 
system 200 has a client/server configuration with database 210, 
application server 220 and front-end server 230. Preferably, 
computer system 200/300 is a system of an R/3 type. 

0153 Preferably, main system 2 00 executes application A as an 
enterprise resource planning ERP application. Preferably, the 
EPR application is selected from the group of: supply chain 
management, customer relationship management, financials, human 
resources, enterprise portals, exchanges, technology, product 
lifecycle management, supplier relationship management, 
business intelligence, business intelligence, mobile business, 
hosted solutions, small and midsize business, industry 
solutions. Preferably, the ERP application is defined by 
instructions that have common keywords, common syntax and 
common semantic with environments selected from the group of: 
ARAB/ 4, Java 2 Platform Enterprise Edition J2EE, and.NET 
framework. Preferably, auxiliary system 300 uses client/server 
configuration 210, 220, 230 of main system 200; the modules of 
auxiliary system 3 00 are distributed such that service module 
310, acquisition module 320, knowledge module 330, and 
inference module 340 are arranged in parallel to application 
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server 220 and to database 210. Preferably, front-end server 
23 0 operates as user- interface for the main system 200 and for 
auxiliary system 300. Preferably, computer system 200/300 uses 
Internet communication between application server 220 and 
front-end server 230. 

0154 Preferably, service module 310 makes basis service functions pf 
main system 200 available for auxiliary system 300. Preferably, 
the basis service functions are selected from the group of 
ABAP/4 workbench, administration, authorizations, batch input, 
data dictionary, dialog control, framework, graphical user 
interface, application program interface, and job. Preferably, 
service module 310 cooperates with main system 200 to obtain 
problem related data D for auxiliary system 300. Preferably, 
service module 310 cooperates with database 210 to test the 
existence of objects, wherein problem related data D comprises 
information about existence and non-existence of the objects. 
Preferably, service module 310 cooperates with database 210 to 
obtain the content of a table entry as problem related data D. 
Preferably, service module 310 records events in the operating 
system of main system 200 by writing to database 210. 
Preferably, service module 310 records problem related data D 
obtained from data consistency check operations of main system 
200. Preferably, service module 310 instructs front-end server 
230 to provide dialogs with user 1000. 

0155 Preferably, service module 310 provides remote function call 
RFC connections with service system 500. Preferably, service 
module 310 monitors application server 220 and database 210 
according to instructions from inference module 340. 

0156 Preferably, acquisition module 32 0 also modifies knowledge 
representations R. Preferably, acquisition module 320 interacts 
with knowledge engineer 1001. Preferably, acquisition module 
320 interacts with knowledge engineer 1000 through tree 322 on 

i 
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a graphical user interface. Preferably, acquisition module 320 
uses tree 322 to represent knowledge representations R as a 
semantic net. 

0157 Preferably, knowledge module 330 is adapted to receive regular 
updates of the knowledge representations R from service system 
500. Preferably, knowledge module 330 stores the knowledge 
representations R in database 210 with entries for specific 
problem P symptoms and corresponding solutions S. Preferably, 
knowledge module 330 stores knowledge representations R in the 
database 210 with entries for predefined solution 
identification rules. Preferably, the solution identification 
rules are provided in a meta language. Preferably, the meta- 
language is derived from ABAP/4 . 

0158 Preferably, knowledge module 330 generates a structured set of 
problem solving strategies. Preferably, knowledge module 330 

> generates solution identification rules with computer 

instructions to automatically solve the problem. Preferably, 
computer system 200/300 is adapted to use the solution 
identification rules for automatically solving the problem. 
Preferably, sets of semantically related solution 
identification rules are grouped together. Preferably , 
knowledge module 330 stores knowledge representations R in a 
plurality of tables in database 210. Preferably, the tables are 
provided prior to activating auxiliary system 300. 

0159 Preferably, inference module 340 identifies the solutions S 
from sets of predefined advices. Preferably, inference module 
340 identifies the solutions S from sets of predefined advices 
that are advices of the application A. Preferably, inference 
module 340 identifies the solutions by applying the knowledge 
representations R. Preferably, inference module 340 applies the 
knowledge representations R in a predefined order. Preferably, 
the predefined order is a sequential order. Preferably, the 
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predefined order is a hierarchical order. Preferably, the 
predefined order is a dynamically adaptive order. Preferably, 
inference module 340 communicates questions to user 1000 via 
front-end server 230. Preferably, inference module 340 
communicates questions that are standard questions. Preferably, 
inference module 340 consecutively numbers the questions. 
Preferably, inference module 340 composes the questions from 
predefined passages that are provided by the application server 
220. Preferably, inference module 340 analyzes responses that 
the user enters in natural language. Preferably, auxiliary 
system 300 conditionally forwards problem P data to service 
system 500. 

0160 Preferably, auxiliary system 300 forwards the problem P data to 
service system 500 with preliminary analysis data based on 
processing with knowledge representations R in auxiliary system 
200. Preferably, auxiliary system 300 forwards problem P data 
for further analysis by a human technician. 

0161 Preferably, auxiliary system 300 forwards problem data P and 
preliminary solutions S to service system 500 in a format that 
allows evaluation in the service system 500. Preferably, main 
system 201 is physically implemented by a first computer, 
service system 500 is implemented by a second computer and 
further main system 202 is implemented by a third computer. 
Preferably, main system 201 is adapted to be operated by a 
first customer, service system 500 is implemented by an 
expertise service provider ESP, and the at least one further 
main system 201 is adapted to be operated by a second customer. 

0162 Preferably, main system 200 and the further main system 201 are 
systems of the same type, but have different release versions. 
Preferably, some of the computers are located at physically 
different locations. Preferably, computer system 200/300 has a 
further module to identify a predefined instructions sequence, 
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wherein the instruction sequence is assigned to solution S that 
is identified by inference module 340. 

0163 FIG. 15 illustrates a simplified block diagram of exemplary 
computer system 999 in general for that the present invention 
can be implemented. System 999 has a plurality of computers 
900, 901, 902 (or even more) . Computer 900 can communicate with 
computers 901 and 902 over network 990. Computer 900 has 
processor 910, memory 920, bus 930, and, optionally, input 
device 940 and output device 950 (I/O devices, user interface 
960) . As illustrated, the invention is implemented by computer 
program product 100 (CPP) , carrier 970 and signal 980. 

0164 In respect to computer 900, computer 901/902 is sometimes 
referred to as "remote computer", computer 901/902 is, for 
example, a server, a peer device or other common network node, 
and typically has many or all of the elements described 
relative to computer 900. 

0165 Computer 900 is, for example, a conventional personal computer 
(PC) , a desktop device or a hand-held device, a multiprocessor 
computer, a pen computer, a microprocessor-based or 
programmable consumer electronics device, a minicomputer, a 
mainframe computer, a personal mobile computing device, a 
mobile phone, a portable or stationary personal computer, a 
palmtop computer or the like. 

0166 Processor 910 is, for example, a central processing unit (CPU) , 
a micro-controller unit (MCU) , digital signal processor (DSP) , 
or the like. 

0167 Memory 920 is elements that temporarily or permanently store 
data and instructions. Although memory 920 is illustrated as 
part of computer 900, memory can also be implemented in network 
990, in computers 901/902 and in processor 910 itself (e.g., 
cache, register) , or elsewhere. Memory 920 can be a read only 
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memory (ROM) , a random access memory (RAM) , or a memory with 
other access options. Memory 920 is physically implemented by 
computer-readable media, for example:, (a) magnetic media, like 
a hard disk, a floppy disk, or other magnetic disk, a tape, a 
cassette tape; (b) optical media, like optical disk (CD-ROM, 
digital versatile disk - DVD) ; (c) semiconductor media, like 
DRAM, SRAM, EPROM, EEPROM, memory stick. 

0168 Optionally, memory 920 is distributed. Portions of memory 920 
can be removable or non- removable. For reading from media and 
for writing in media, computer 900 uses well-known devices, for 
example, disk drives, or tape drives. 

0169 Memory 920 stores modules such as, for example, a basic input 
output system (BIOS) , an operating system (OS) , a program 
library, a compiler, an interpreter, and a text- processing 
tool. Modules are commercially available and can be installed 
on computer 900. For simplicity, these modules are not 
illustrated. 

0170 CPP 100 has program instructions and - optionally - data that 
cause processor 910 to execute method steps of the present 
invention. In other words, CPP 100 can control the operation of 
computer 900 and its interaction in network system 999 so that 
is operates to perform in accordance with the invention. For 
example and without the intention to be limiting, CPP 100 can 
be available as source code in any programming language, and as 
object code ("binary code") in a compiled form. 

0171 Although CPP 100 is illustrated as being stored in memory 920, 
CPP 100 can be located elsewhere. CPP 100 can also be embodied 
in carrier 970. 

0172 Carrier 970 is illustrated outside computer 900. For 
communicating CPP 100 to computer 900, carrier 970 is 
conveniently inserted into input device 940. Carrier 970 is 
implemented as any computer readable medium, such as a medium 
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largely explained above (cf. memory 920). Generally, carrier 
970 is an article of manufacture having a computer readable 
medium with computer readable program code to cause the 
computer to perform methods of the present invention. Further, 
signal 980 can also embody computer program product 100 . 

0173 Having described CPP 100, carrier 970, and signal 980 in 
connection with computer 900 is convenient. Optionally, further 
carriers and further signals embody computer program products 
(CPP) to be executed by further processors in computers 901 and 
902. 

0174 Input device 940 provides data and instructions for processing 
by computer 900. Device 940 can be a keyboard, a pointing 
device (e.g., mouse, trackball, cursor direction keys), 
microphone, joystick, game pad, scanner, or disc drive. 
Although, the examples are devices with human interaction, 
device 940 can also be a device without human interaction, for 
example, a wireless receiver (e.g., with satellite dish or 
terrestrial antenna), a sensor (e.g., a thermometer), a counter 
(e.g., a goods counter in a factory). Input device 940 can 
serve to read carrier 970. 

0175 Output device 950 presents instructions and data that have been 
processed. For example, this can be a monitor or a display, 
(cathode ray tube (CRT) , flat panel display, liquid crystal 
display (LCD) , speaker, printer, plotter, vibration alert 
device. Output device 950 can communicate with the user, but it 
can also communicate with further computers. 

0176 Input device 940 and output device 950 can be combined to a 
single device. Any device 940 and 950 can be provided optional. 

0177 Bus 930 and network 990 provide logical and physical 
connections by conveying instruction and data signals. While 
connections inside computer 900 are conveniently referred to as 
"bus 93 0", connections between computers 900-902 are referred 
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to as "network 990". Optionally, network 990 includes gateways 
which are computers that specialize in data transmission and 
protocol conversion . 

0178 Devices 940 and 950 are coupled to computer 900 by bus 930 (as 
illustrated) or by network 990 (optional) . While the signals 
inside computer 900 are mostly electrical signals, the signals 
in network are electrical, electromagnetic, optical or wireless 
(radio) signals, 

0179 Networks are commonplace in offices, enterprise -wide computer 
networks, intranets and the Internet (e.g., world wide web) . 
Network 990 can be a wired or a wireless network. To name a few 
network implementations, network 990 can be, for example, a 
local area network (LAN) , a wide area network (WAN) , a public 
switched telephone network (PSTN) ; a Integrated Services 
Digital Network (ISDN) , an infra-red (IR) link, a radio link, 
like Universal Mobile Telecommunications System (UMTS) , Global 
System for Mobile Communication (GSM) , Code Division Multiple 
Access (CDMA), or satellite link. 

0180 A variety of transmission protocols, data formats and 
conventions is known, for example, as transmission control 
protocol /internet protocol (TCP/IP), hypertext transfer 
protocol (HTTP) , secure HTTP, wireless application protocol 

(WAP) , unique resource locator (URL) , a unique resource 
identifier (URI) , hypertext markup language (HTML) , extensible 
markup language (XML) , extensible hypertext markup language 

(XHTML) , wireless markup language (WML) , Standard Generalized 
Markup Language (SGML) . 

0181 Interfaces coupled between the elements are also well known in 
the art. For simplicity, interfaces are not illustrated. An 
interface can be, for example, a serial port interface, a 
parallel port interface, a game port, a universal serial bus 
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(USB) interface, an internal or external modem, a video 
adapter, or a sound card. 
0182 Computer and program are closely related. As used hereinafter, 
phrases, such as "the computer provides" and "the program 
provides", are convenient abbreviation to express actions by a 
computer that is controlled by a program. 
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Claims 

1. Computer system (200/3 00) with a main system (200) to execute 
an application (A) in cooperation with a human user (1000) , the 
computer system with an auxiliary system (300) to evaluate 
problems (P) in the main system (200) with a service module 
(310) to collect problem related data (D) from the main system 
(200) , an acquisition module (320) to acquire knowledge 
representations (R) , a knowledge module (330) to store the 
knowledge representations (R) , an inference module (340) to 
process problem related data (D) with knowledge representations 
(R) to identify solutions (S) , the inference module (340) also 
to forward the solutions (S) through the service module (310) 
to the main system (200), the computer system (200/300) 
characterized in that the auxiliary system (200) distinguishes 
context of the problems (P) and distinguishes versions of the 
main system (200) . 

2. Computer system (200/300) of claim .1, wherein the auxiliary 
system (200) also distinguishes context and versions relating 
to the application (A) . 

3. Computer system (200/300) of claim 2, wherein the auxiliary 
system (200). distinguishes context and versions by using a 
check lexicon (331) in the knowledge module (330) . 

4. Computer system (200/300) of claim 3, wherein the check lexicon 
(331) lists details for the knowledge representations (R) , 
wherein the details depend on a version of the main system. 
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5. Computer system (200/300) of claim 3, wherein the check lexicon 
(331) lists details for the knowledge representations (R) , 
wherein the details depend on a version of the application (A) . 

6. Computer system (200/300) of claim 3, wherein the check lexicon 
(3 31) lists details for the knowledge representations (R) , 
wherein the details depend on the context of the problem (P) . 

7. Computer system (200/300) of claim 3, wherein the check lexicon 
(331) lists details for the knowledge representations that 
depend on a version of the main system (200) . 

8. Computer system (200/300) of claim 3, wherein the check lexicon 
uses parameters for versions and context. 

9. Computer system (200/300) of claim 1, wherein the knowledge 
module (330) distinguishes contexts that are predefined sets of 
knowledge representations (R) . 

10. Computer system (200/300) of claim 1, wherein the knowledge 
module (330) distinguishes context with primary context and 
secondary context, wherein the secondary context is referenced 
from the first context. 

11. Computer system (200/300) of claim 1, wherein the knowledge 
module (330) makes knowledge representations (R) selectively 
available or non-available according to a selected context. 
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12. Inference module (x40) with expertise functionality for 

evaluating problems (P) in a main computer system (200) that 
executes an application (A) , wherein the inference module (x40) 
is adapted to process problem related data (D) with knowledge 
representations (R) to identify solutions (S) , the inference 
module (x40) characterized in that the inference module (x40) 
distinguishes problem related data (D) in context classes. 



2002P10027WO 



WO 2004/040510 



CT/EP2003/010246 



200 
MAIN 

300" 
AUX 



1/15 

• 


USER 

a t\nn I 

1 000~\_1 


MM — 




310 SERVICE 


T COLLECT / 

1 / 


340 INFERENCE 


/t\*S FORWARD 




VJV STORE 


320 ACQUISITION 


— 

x ACQUIRE 



FIG.1 



WO 2004/040510 ^) ^^PCT/EP2003/010246 

2/15 



310 



230 



FRONT.END 



220 



APPLICATION 



210 



DATABASE 





INFERENCE ' 


SERVICE 






KNOWLEDGE 




ACQU 



340 



330 



320 



— V — 

200 



300 



COMPUTER SYSTEM 200/300 



FIG. 2 



WO 2004/040510 ^^PCT/EP2003/010246 

3/15 



230 



220 



210- 



FRONT- END SERVER 
DIALOG 



APPLICATION SERVER 
MONITOR 

CONSISTENCY CHECK 



DATABASE 

DOES OBJECT EXIST ? 
TABLE ENTRY 
WRITE OPERATION 



310 

i 

SERVICE MODULE 
BASIS FUNCTIONS 



200 



SERVICE MODULE 310 



FIG. 3 



WO 2004/040510 ^) ^^PCT/EP2003/010246 

4/15 



PATCH TYPE 



YES 




PATCH SOURCE 



Z 




CD 



OSS 



INTERNET 



TREE 
322 



INSERT 
OBJECT 




^—1001 



ACQUISITION MODULE 320 



FIG. 4 



WO 2004/040510 ^^PCT/EP2003/0 10246 



5/15 



331 LEXICON 



VERSION 
1.0 

i 20 


Pa R 







UPDATES 



► 

FIRST CONTEXT SECOND CONTEXT 



KNOWLEDGE MODULE 330 



FIG. 5 



WO 2004/040510 



CT/EP2003/010246 



6/15 



SOLUTION IDENTIFIER 
SET OF ADVICES 
R TO APPLY 
R1,R2,R3 

R1,R21,R21,R31,R32 
IF THEN 

Q1,Q2,Q3 RESERVOIR 
LANGUAGE ANALYZER 



INFERENCE MODULE 340 



FIG. 6 



WO 2004/040510 ^^PCT/EP2003/010246 

7/15 



200 / 300 
MAIN/AUX 



500 



NETWORK 



SERVICE 



510 
520 
530 
540 



1 

/s~1002 

SERVICE 
ENGINEER 



FIRST DISTRIBUTED SYSTEM LANDSCAPE 



FIG. 7 



WO 2004/040510 



8/15 



'CT/EP2003/010246 



MAIN 




SERVICE 




MAIN 






201 


i 

500 


i 

202 



CUSTOMER 1 EXPERTISE CUSTOMER 2 

SERVICE 
PROVIDER 



SECOND DISTRIBUTED SYSTEM LANDSCAPE 



FIG. 8 



WO 2004/040510 


• 

9/15 


^^PCT/EP2003/010246 




collecting problem related data (D) 






r 




acquiring knowledge representations (R) 









441 



442 




processing data (D) and representations (R) to 
identify solutions (S) 



forwarding solutions (S) 



400 



FIG. 9 



WO 2004/040510 




CT/EP2003/010246 



6 

10/15 



INTERACTION 
REQUIRED ? 



YES 





NO 



SYSTEM / SYSTEM 



INITIATED 



24 



U 



U 1 

U 








DIALOG 


VOLUNTARY 



—23 


"\ 

—25 


START BY 


USER 





30 

1 



NORMAL 
OPERATION 



AUTOMATIC 
EVALUATION 




INITIATED BY ? 



DIALOG 
MANDATORY 





S 




~26 


START 




AUTOMATICALLY 



FIG. 10 



WO 2004/040510 



CT/EP2003/010246 



50 



11/15 



START 



PROCESS D TO 
IDENTIFY CONTEXT 



SELECT R FOR 
CONTEXT 



PROCESS D. R 




'YES 



10 



20 



30 



END 



FIG. 11 



^^PCT/EP2003/010246 

12/15 



WO 2004/040510 




30 



65 



10' 



DETECTING PROBLEM 



20 



PROCESSING BY AUX SYSTEM 



SUCCESS, 



.FAILURE 



IDENTIFY S 
BY AUX 
SYSTEM 



FORWARDING 
TO SERVICE 
SYSTEM 



PROCESSING 



40 



50 



SUCCESS. 



.FAILURE 



60' 



IDENTIFY S BY 
SERVICE SYSTEM 



SOLVING BY 
HUMAN 



SUPPLY NEW R 
TO AUX SYSTEM 
FOR FURTHER 
PROCESSING 



T 

70 



FIG. 12 



WO 2004/040510 ^^PCT/EP2003/010246 

13/15 



CO 

1 1 

CO UJ 

LU Q£ 



CM 



— LU 



LU 
CO 



CO 



CO 
LU 

8 » 

LU >- 

O LU 

O P 

a: z 



s 9 

LU * £L 

I— CO 

CO LU 

>- O 

CO Q 

=3 *" 

< CQ 



O LU 

LU S 

I— z 

£ O 

q a: 



LU 



LU 



X s 

LU LU 

— _l 

a: cq 

LU O 

co a: 



CO 

ft: 

o 
a. 



CM 



52 

CO 



CO 

I— 
o 



o 
o 



CO 



LU 
I— 

CO 



"j CO 

8 3 



CO 2 

I— LU 

o 

UJ Q 

LU < 

Q |_ 

m LU 

1= s 

CO z 

co 2 

X ^ 



CO 



CQ 
O 
ftT 



CD 

z 

CO 
CO 
LU 
O 

§ 



LU 
O 



LU 



CO 
O 



O 

CO 



0 s 

I- LU 

<g CO 

5 co 

a: lu 

1 ^ 

qc a: 

O LU 

U_ CO 



CO 

CD 



WO 2004/040510 



CT/EP2003/010246 



14/15 



© 



200 









X40 







300 




500 



© 












X40 




VERSIONS 
331 



201,202 



FIG. 14 



(12) IN TERNATIONA^APPLI CATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



2 6 JAM 2005 



(19) World Intellectual Property 
Organization 

International Bureau 

(43) International Publication Date 
13 May 2004 (13.05.2004) 



mm 

mm 



PCT 



(10) International Publication Number 

WO 2004/040510 A3 



(51) International Patent Classification 7 : 
(21) International Application Number: 



G06N 5/02 



PCT/EP2003/0 10246 

(22) International Filing Date: 

15 September 2003 (15.09.2003) 



(25) Filing Language: 

(26) Publication Language: 



English 
English 



(30) Priority Data: 

02024530.4 



31 October 2002 (31.10.2002) EP 



(71) Applicant (for all designated States except US): SAP AK- 
TIENGESELLS CHAFT [DE/DE]; Neurottstr. 16, 69190 
Walldorf (DE). 

(72) Inventor; and 

(75) Inventor/Applicant (for US only): AREND, Thomas 
[DE/DE]; N 4, 15, 68161 Mannheim (DE). 

(81) Designated States (national): AE, AG, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU, 



CZ, DE, DK, DM, DZ, EC, EE, EG, ES, FI, GB, GD, GE, 
GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, 
KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, 
MN, MW, MX, MZ, NI, NO, NZ, OM, PG, PH, PL, PT, 
RO, RU, SC, SD, SE, SG, SK, SL, SY, TJ, TM, TN, TR, 
TT, TZ, UA, UG, US, UZ, VC, VN, YU, ZA, ZM, ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM, ZW), 
Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), 
European patent (AT, BE, BG, CH, CY, CZ, DE, DK, EE, 
ES, FI, FR, GB, GR, HU, IE, IT, LU, MC, NL, PT, RO, 
SE, SI, SK, TR), OAPI patent (BF, BJ, CF, CG, CI, CM, 
GA, GN, GQ, GW, ML, MR, NE, SN, TD, TG). 

Published: 

— with international search report 

— before the expiration of the time limit for amending the 
claims and to be republished in the event of ^receipt of 
amendments 

(88) Date of publication of the international search report: 

24 June 2004 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



(54) Title: IDENTIFYING SOLUTIONS TO COMPUTER PROBLEMS BY EXPERT SYSTEM USING CONTEXTS AND DIS- 
TINGUISHING VERSIONS 



USER 



200-" 
MAIN 

300- 
AUX 



IT) 





(?)— ( 




310 SERVICE | 


COLLECT / 


340 INFERENCE 


^(J^FORWARD 


330 KNOWLEDGE ( 


STORE 


320 ACQUISITION 


^ 

x ACQUIRE 



^ (57) Abstract: A computer system (200/300) has a main system (200) to execute an application (A) in cooperation with a human 
O user (1000). The auxiliary system (300) evaluates problems (P) in the main system (200). The auxiliary system (300) has a service 
® module (310) to collect problem related data (D) from the main system (200), an acquisition module (320) to acquire knowledge 
^ representations (R), a knowledge module (330) to store knowledge representations (R), an inference module (340) for processing 
Q problem related data (D) with knowledge representations (R) to identify solutions (S) and for forwarding the solutions (S) through 
the service module (310) to the main system (200). The auxiliary system (200) distinguishes context of the problems (P) and distin- 
^ guishes versions of the main system (200). 



NATIONAL SEARCH REPORT 



r# 

Inte^^bnol Application No 

PCT/EP 03/10246 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 G06N5/02 



According to International Patent Classification <IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 606N G06F 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the International search (name of data base and. where practical, search terms used) 

EPO-Internal , WPI Data, PAJ 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category • Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



US 6 295 525 Bl (GRAHAM JAMEY ET AL) 
25 September 2001 (2001-09-25) 
abstract 

column 1, line 42 - line 51 
column 2, line 9 - line 46 
column 5, line 52 - line 60 
column 13, line 9 - line 26 

-/-- 



1 

12 



m 



Further documents are listed in the continuation of box C- 



Patent family members are listed In annex. 



* Special categories ol cited documents : 

■A* document defining the general state of the art which is not 

considered to be of particular relevance 
"E" earlier document but published on or after the International 

filing date 

V document which may throw doubts on priority ctalm(s)or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

•O* document referring to an oral disclosure, use, exhibition or 
other means 

■P" document published prior to the international filing date but 
later than the priority date claimed 



T* later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

•X' document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

■Y" document of particular relevance; the claimed Invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art 

document member of the same patent family 



Date of the actual completion of the international search 



16 April 2004 



Date of mailing of the International search report 



06/05/2004 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
TeL (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



Kingma, Y 



Form PCT/1SA/210 (second sheet) (January 2004) 



NATIONAL SEARCH REPORT 




Int. 



al Application No 

PCT7EP 03/10246 



C(Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category • 



Citation ol document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



SHUTT T S ET AL: "COPRA: Computer 

Operations Problem Resolution Assistant" 

1 March 1993 (1993-03-01), PROCEEDINGS OF 

THE CONFERENCE ON ARTIFICIAL INTELLIGENCE 

FOR APPLICATIONS. ORLANDO , MAR. 1-5, 

1993, LOS ALAMITOS, IEEE COMP. SOC. PRESS, 

US, VOL. CONF. 9, PAGE(S) 107-113 , 

XP010125568 

ISBN: 0-8186-3840-0 

abstract 

page 108, right-hand column, line 47 - 
page 109, left-hand column, line 18 



1,12 



Form PCTASA/210 (continuation ot second shoot) (January 2004) 



won 



&NATIONAL SEARCH REPORT 

nformatfon on patent family members 



Interatrial Application No 

PCT/EP 03/10246 



Patent document 
cited in search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 


IK n?Q5R?R 


R1 


25-09-2001 


US 


6049792 A 


1 1 Ail OAAA 

11-04-2000 




us 


6041182 A 


21-03-2000 








us 


5546502 A 


13-08-1996 








us 


2001051938 Al 










6B 


2329989 A ,B 


07-04-1999 








HK 


1019797 Al 


13-07-2001 








JP 


11167452 A 


22-06-1999 








DE 


616288 Tl 


30-11-1995 








EP 


0616288 A2 


21-09-1994 








JP 


6274300 A 


30-09-1994 








JP 


2004046813 A 


12-02-2004 



Form PCT/ISA/210 (patent family annex) {January 2004) 



